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SYSTEM AND METHOD FOR DETERMINING A SOURCE OF AN INTERNET 

PROTOCOL PACKET 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application incorporates by reference U.S. patent application entitled, "System 
and Method for Determining Flow Quality Statistics for Real-Time Transport Protocol Data 
Flows," filed on July 23, 2001, and having serial number 09/91 1,256; U.S. patent application 
entitled, "System and Method for Providing Rapid Rerouting of Real-Time Multimedia 
Flows," filed on July 23, 2001, and having serial number 09/91 1,304; U.S. patent application 
entitled, "System and Method for Providing Encryption for Rerouting of Real-Time 
Multimedia Flows," filed on August 28, 2001, and having serial number 09/941,229; and 
U.S. patent application entitled, "System and Method for Improving Communication 
Between a Switched Network and a Packet Network," filed on November 2, 2001, having 
serial number (To Be Assigned) and attorney docket number 0501 15-1 110, all of the 
foregoing disclosures of which are incorporated by reference herein in their entirety. 

FIELD OF THE INVENTION 

The present invention generally relates to telecommunications and, more particularly, 
is related to a system and method for determining a source of a received Internet protocol 
packet. 

BACKGROUND OF THE INVENTION 

The public switched telephone network (PSTN) has evolved into an efficient real- 
time, multimedia communication session tool, wherein users can pick up any one of nearly 
one billion telephones and dial any one of nearly one billion endpoints. Several 
developments have enabled this automated network, such as numbering plans, distributed 
electronic switching and routing, and networked signaling systems. 
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Similar to the manner in which the PSTN is based on a hierarchy, the Internet is based 
on an Internet protocol (IP). IP messages, or multimedia packets, are routed or forwarded 
from a source of a multimedia flow to a destination of the multimedia flow. Each multimedia 
packet comprises an IP address, which, in Internet protocol version 4 (IPv4), for example, has 
5 32 bits. Each IP address also has a certain number of bits dedicated to a network portion and 
a certain number of bits dedicated to a host portion. It should be noted that the term 
"multimedia" utilized herein is intended to comprise one or more of the following: voice, 
data, text, graphics, animation, and/or discrete media. 

More specifically, multimedia packets comprise a header portion and an IP packet 
10 data portion. The header portion of the multimedia packet, at a minimum, comprises at least 
a source portion and a destination portion, wherein the source portion identifies a source 
address from which the packet originated, and the destination portion identifies a destination 

SH address to which the packet is addressed. It should be noted that additional portions of the 

I y 

header portion may be provided, in addition to the source portion and the destination portion 
15 such as, but not limited to, a real-time packet header or a real-time control packet header. 
The IP packet data portion of the multimedia packet comprises the remaining portion of the 
multimedia packet, which comprises data that is being transmitted to a destination device 
located at the destination address. 

As the multimedia packet is received by different devices on a path taken by the 
20 multimedia packet to the destination device, it is common for the source and/or destination 
portions of the multimedia packet to change properties, thereby reflecting a most recent 
source and destination. 

Therefore, it is difficult to determine the original source of a multimedia packet. 
Having knowledge of the original source of a multimedia packet allows the destination 



FH ; i 



2 



TKHR Docket No.: 50115-1110 

device to accept or decline acceptance of the multimedia packet based upon the original 
source of the multimedia packet. 

The acceptance or denial of multimedia packets based upon the original source is a 
characteristic of devices such as, but not limited to, firewalls. Unfortunately, since the header 
portion of the multimedia packet is changed by devices within the transmission path to the 
destination device, the original source of the multimedia packet is not known. Since the 
original source is not known, the destination device is not capable of accurately declining 
receipt of multimedia packets from a predefined source. 

SUMMARY OF THE INVENTION 

In light of the foregoing, the preferred embodiment of the present invention generally 
relates to a system for accurately determining an original source of a received multimedia 
packet. 

Generally, with reference to the structure of the source determination system, the 
system utilizes a memory and a processor. The processor compares a destination address of 
the IP packet to a first destination address stored within a first destination address cell of the 
memory, and compares a destination port of the IP packet to a first destination port stored 
within a first destination port cell of the memory. The processor also compares a source 
address of the IP packet to a first source address stored within a first source address cell of 
the memory, and compares a source port of the IP packet to a first source port stored within a 
first source port cell of the memory, wherein the stored first source address and the stored 
first source port are associated with the stored first destination address and the stored first 
destination port. The processor also stores the source address and source port of the IP 
packet within the memory to determine the source of the IP packet if: the destination address 
and destination port of the IP packet match the stored first destination address and stored first 
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destination port; the source address and source port of the IP packet do not match the stored 
first source address and stored first source port; and the stored first source address and stored 
first source port are universally accepted bits. 

It should be noted that the present invention can also be viewed as providing a method 
for determining a source of an IP packet. 

Other systems and methods of the present invention will be or become apparent to one 
with skill in the art upon examination of the following drawings and detailed description. It 
is intended that all such additional systems, methods, features, and advantages be included 
within this description, be within the scope of the present invention, and be protected by the 
accompanying claims. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention can be better understood with reference to the following drawings. The 
components of the drawings are not necessarily to scale, emphasis instead being placed upon 
clearly illustrating the principles of the present invention. Moreover, in the drawings, like 
referenced numerals designate corresponding parts throughout the several views. 

FIG. 1 is a block diagram illustrating a communication network for providing the 
present source determination system. 

FIG. 2 is a block diagram further illustrating the media router of FIG. 1. 

FIG. 3 is a simplified diagram illustrating parts of a multimedia packet that may be 
received by the media router of FIG. 2. 

FIG. 4 is a multimedia packet flow table located within a CAM of the media router of 

FIG. 2. 

FIG. 5 A is a block diagram illustrating a multimedia packet flow table utilized to 
provide an example of use of the present source determination system. 

FIG. 5B is a block diagram illustrating the multimedia packet flow table of FIG. 5 A 
after addition of a fifth table group. 

FIG. 5C is a block diagram illustrating the multimedia packet flow table of FIG. 5B 
after removal of a second table group. 
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DETAILED DESCRIPTION OF THE PREFER RED EMBODIMENT 

The source determination system of the present invention can be implemented in 
software, firmware, hardware, or a combination thereof. In the preferred embodiment of the 
invention, which is intended to be a non-limiting example, a portion of the system is 
implemented in software that is executed by a network processor. 

The software based portion of the source determination system, which comprises an 
ordered listing of executable instructions for implementing logical functions, can be 
embodied in any computer-readable medium for use by, or in connection with, an instruction 
execution system, apparatus, or device such as a computer-based system processor containing 
system, or other system that can fetch the instructions from the instruction execution system, 
apparatus, or device and execute the instructions. In the context of this document, a 
"computer-readable medium" can be any means that can contain, store, communicate, 
propagate or transport the program for use by or in connection with the instruction execution 
system, apparatus or device. 

The computer-readable medium can be, for example, but not limited to, an electronic, 
magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or 
propagation medium. More specific examples (a non-exhaustive list) of the computer- 
readable medium would include the following: an electrical connection (electronic) having 
one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) 
(magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only 
memory (EPROM or Flash memory) (magnetic), an optical fiber (optical), and a portable 
compact disk read-only memory (CD ROM) (optical). Note that the computer-readable 
medium could even be paper or another suitable medium upon which the program is printed, 
as the program can be electronically captured, via for instance, optical scanning of the paper 
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or other medium, then compiled, interpreted or otherwise processed in a suitable manner, if 
necessary, and then stored in a computer memory. 

In the transmission of multimedia data packets from a first endpoint to a second 
endpoint, it is desirable to process multiple transmission routes and to select a best 
transmission route. An example of a system that provides for route processing and selection 
is provided by the co-pending U.S. patent application entitled, "System and Method for 
Assisting in Controlling Real-time Transport Protocol Flow Through Multiple Networks via 
Multi-media Flow Routing/' by MeLampy et al, filed on July 23, 2001, and having serial 
number 09/911,256 (hereinafter, "the 6 256 patent application"), the disclosure of which is 
hereby incorporated by reference in its entirety. 

The '256 patent application teaches use of a session router to select multiple routes 
and process them in order, selecting from a set of session initiation protocol (SIP) agent(s) 
that are otherwise equal using various distribution strategies. This process leads to managing 
the path of the resulting real-time transport protocol (RTP) flow. The US patent application 
entitled "System and Method for Providing Rapid Rerouting of Real Time Multi-media 
Flows," by MeLampy et aL, filed on July 23, 2001, having serial number 09/911,304 
(hereinafter "the '304 patent application"), the disclosure of which in hereby incorporated by 
reference in its entirety, teaches use of media routers for guiding the resulting RTP flows 
selected and processed by the session router through certain thresholds. Therefore, the 
combination of the abovementioned c 256 and '304 patent applications creates a high-quality 
border between various IP networks. Without these mechanisms, data packets would flow 
whichever way networks would allow. 

FIG. 1 is a block diagram illustrating a communication network 102, wherein the use 
of a session router 104 and media router 106 is demonstrated, for implementation of the 
present source determination system. As shown by FIG. 1, a first session initiation protocol 
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(SEP) device 112, herein a SIP phone, such as those produced by and commercially available 
from Pingtel of Massachusetts, U.S.A., is connected to a second SIP device 1 14, herein a 
second SIP phone. Communication between the first SIP phone 1 12 and the second SIP 
phone 1 14 is enabled by the session router 104 and the media router 106 and may be 
5 provided via the Internet. It should be noted that communication between the first SIP phone 
1 12 and the second SIP phone 1 14 may instead be provided via a wide area network (WAN) 
or local area network (LAN). Also, the Internet may instead be a data network domain, if the 
U media router 106 is utilized between two domains within the Internet, with the first SIP phone 
O 1 12 in a first domain and the second SIP phone 1 14 is a second domain. 
Ul io The session router 104 provides SIP and telephony routing over IP (TRIP) protocol 

^ support as described in detail by the presently pending application entitled, "System and 

% t Method for Assisting in Controlling Real-Time Transport Protocol Flow Through Multiple 

fU Networks," by MeLampy et. al 9 having serial number 09/844,204, and filed on April 27, 

s 

p 2001 , the disclosure of which is incorporated herein by its entirety. 

ru 

15 It should be noted that additional session routers and media routers may be provided 

within the communication network 102. In fact, communication from a first media router 
may be to a second media router, a session router, a SIP device, and/or a non-SIP device 
located in a LAN, WAN, or other location. 

The introduction of media routers into the real-time multimedia flow forces 

20 multimedia packets through a known interface. FIG. 2 is a block diagram further illustrating 
the media router 106 of FIG. 1. As shown by FIG. 2, the media router 106 comprises a flow 
quality management engine 132, a traffic manager 134, a communication interface 136, a 
host processor 138, a network processor 142, input devices 144 and output devices 146, and a 
content addressable memory (CAM) 148, or a ternary database, all of which communicate 
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within the media router 106 via a local link 152. Each of the above-mentioned are described 
in detail in the presently pending '304 patent application. 

Specifically, the traffic manager 134 is preferably used for measuring and enforcing 
IP session multimedia flow rates, or traffic, for providing traffic measurement. An example 
of a suitable traffic manager among the many possible implementations is a commercially 
available NPX5700 traffic manager sold by MMC Networks located in California, USA. 
Essentially, the traffic manager 134 measures the number of multimedia packets that flow 
through the communication interface 136. The traffic manager 134 works in concert with the 
network processor 142 such that once a forwarding decision is made, the traffic manager 134 
queues the received packet into its respective IP flow and associated priority. 

As is known in the art, the traffic manager 134 comprises a memory for temporarily 
storing received multimedia packets. From an inbound perspective, the traffic manager 134 
is able to monitor RTP multimedia flows and enforce maximum data rates by either dropping 
multimedia packets or marking them as eligible for discarding if they are outside a bandwidth 
allocated for the multimedia flow. The traffic manager 134 may also be instructed by the 
session router 104 to accept a specific amount of multimedia in accordance with an allocated 
bandwidth and bit rate. Therefore, if multimedia is received at a higher bit rate than allowed 
by the session router 104, the multimedia received at the higher bit rate is not transmitted. It 
should be noted that the characteristics specified by the session router 104 may instead be 
programmed directly into the media router 106 without using the session router 104. 

The network processor 142 provides translation services within the media router 106. 
The translation services performed by the network processor 142 comprise the capability to 
translate a source address, destination address, source port, destination port or any 
combination of these fields. In addition, the network processor 142 is capable of removing 
and/or inserting a multi-protocol label switching (MPLS) tag in a multimedia packet, hi 
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addition, the network processor 142 is capable of inserting or modifying a diffserv codepoint 
located within the IP header of a multimedia packet, which is used to modify priority of the 
multimedia packets. 

The flow quality management engine 132 provides quality measurement services on a 
per flow basis, wherein a multimedia flow is defined by a source IP address, a destination DP 
address, a source port, and/or a destination port. Quality measurement preferably comprises 
maintaining current statistics for the flow within the network processor 142, as well as 
aggregate and/or min/max statistics for the flow where applicable. 

Examples of statistics that may be collected include latency, jitter and packet loss for 
a pre-defined window of time. It should be noted that the window can be identified via the 
session router 104 or the media router 106. Aggregate statistics may include transmitted 
packets, dropped packets and/or duplicate packets. Minimum and maximum statistics, 
otherwise referred to as "boundary statistics," may also be collected which may include 
latency, jitter and packet loss per window of time. The flow quality management engine 132 
also provides the detection and correction of upstream and/or downstream failures in the 
transmission of RTP data packets. 

The host processor 138, similar to the traffic manager 134, provides detection and 
correction of upstream and downstream failures. Methods used by the host processor 138 to 
detect and correct upstream and downstream failures in the transmission of RTP multimedia 
packets include, but are not limited to, the use of link failures and external management 
events. 
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The CAM 148 stores translations or bindings previously determined by "open/bin" 
requests for fast access by the network processor 142. Open/bind requests are discussed in 
detail within the '304 patent application. The CAM 148 may also be used to store media 
access control addresses to IP mappings as discussed below. There are many possible 
5 implementations of the CAM 148. An example of an external search engine is manufactured 
by and commercially available from Netlogic Microsystems, Inc, of Mountain View, CA. 

The media router 106 is capable of generating flow quality statistics for RTP 
multimedia flows. Further, the media router 106 is able to generate the flow quality statistics 
from RTP packets as they flow through the communication network 102. In certain 
10 situations the statistics are only relevant for links between media routers if more than one 
media router is utilized. 

Preferably, the media router 106 stores one or more statistics for each flow. These 
statistics may include, but are not limited to, latency, jitter, a number of octets per packet, 
and/or the number of dropped packets. It should be noted that other statistics may also be 
1 5 stored with regard to each multimedia flow through the media router 118. Assuming that 
more than one media router is utilized, to generate statistics for each multimedia flow, the 
media router 106 runs a proprietary version of a protocol, such as, but not limited to, real- 
time transport control protocol (RTCP), between connected media routers to determine 
latency. Jitter and dropped packet statistics can be generated autonomously by the media 
20 router 1 06. The following describes how latency, jitter and dropped packets can be 
determined in the absence of RTCP information. 

In order to measure latency for a data flow, the media router 106 communicates with 
another endpoint on the multimedia flow. The other endpoint may be another media router, 
although it need not be. As an example, the other endpoint may be a SIP phone. Assuming, 
25 for exemplary purposes, that the other endpoint is a media router, the subject of the 
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communication between media routers is a test packet that is utilized to determine RTP data 
flow latency. The multimedia router 106 receiving the looped packet compares when the 
packet was received to when the packet was sent, thereby determining a round trip time. The 
round trip time is then cut in half to approximate the one-way time, which is the latency. 

Rather than using a proprietary way to perform packet looping, RTCP packet format 
can be used between two media routers. This format allows extraction of a timestamp of the 
sender (from a send report) and placing the timestamp into the looped packet (in a receive 
report), as well as an estimate of how long it took to loop the packet. 

Jitter is a measurement of the variation of the gap between packets on a flow. An 
alternative definition is that jitter is the variance in latency for a multimedia flow. The media 
router 106 can measure jitter for an RTP data flow as it transits the media router 106. When a 
data packet reaches the network processor 142, a timer is started that runs until the next 
packet for that RTP data flow arrives. The time gap between packet receipt is added to an 
aggregate to maintain a "mean" jitter value. The "mean" jitter value can also be compared to 
a min/max value in a flow record to determine if a new min/max jitter value is established. It 
should be noted that the flow record may be located within a network processor memory (not 
shown) that is located within the network processor 142. It should also be noted that the 
memories located within the media router 106 may all be located within a single memory 
stored within, or outside of the media router 1 06. In the situation where this process may be 
too processor intensive, jitter samples can be aggregated and min/max calculations can be 
performed on a periodic basis using the aggregated information. 

Dropped packet, or lost packet, processing in the absence of an RTCP based 
mechanism may be accomplished on an RTP flow using two scoreboard arrays of booleans 
that are used to track when a packet is missing, and whether the packet appears within a jitter 
window. Alternate methods of processing multimedia packets may be used. It should be 
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noted that a jitter window is typically implemented in voice gateways to compensate for 
fluctuating network conditions. The jitter window is a packet buffer that holds incoming 
packets for a specified amount of time, before forwarding them for decompression. The 
process has the effect of smoothing the packet flow, thereby increasing the resiliency of a 
compressor/de-compressor (CODEC) to packet loss, delaying packets, and producing other 
transmission effects. Preferably, the jitter window is defined by the session router 104, 
although it may be directly defined via the media router 106. 

Each entry in a scoreboard array represents whether a media router has received a 
packet having a specific sequence number. The scoreboard array may be located within the 
network processor memory or within any local or distant memory. Each scoreboard array 
also has a counter which tracks how many entries have been marked "missing." Preferably, 
all entries are initially marked as "received." 

As the sequence numbers are tracked in the network processor 142 and missing 
packets are detected, specifically, a packet with a sequence number that has incremented 
more than one, the appropriate entry in the current array is marked "missing" and the missing 
counter is incremented. Preferably, two arrays are sized as the maximum number of packets 
in the jitter window. These two arrays are hereinafter referred to as the current array and the 
aged array. When the current array reaches the maximum jitter window, the aged array is re- 
initialized and becomes the current array and the current array becomes the aged array. 
Before the aged array is erased, the counter for dropped packets is retrieved and accumulated 
for the data flow. 

However, if an out of order old multimedia packet is received, wherein the sequence 
number is less than the current sequence number, the network processor 142 searches for the 
sequence number entry in either the current or aged array, depending on lateness of the 
packet. If the network processor 142 finds the entry marked missing and changes the entry, 
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the network processor 142 then decrements a missing multimedia packet counter of the array 
that is used for keeping track of missing packets. If the packet is not marked as missing, then 
the network processor 142 designates that the packet is a duplicate. If the sequence number 
is so old that the multimedia packet dates back further than the depth of the jitter window, 
then the network processor 142 does not perform a lookup. It should be noted that this 
method of performing dropped packet counting is more accurate than that obtainable using 
RTCP. 

Returning to FIG. 1, typically, there is at least one intervening device 116 located 
between the first SIP phone 1 12 and the media router 106. The intervening device 1 16 may 
be a router, such as, but not limited to, a border router, a firewall, or any other 
communication device. It should be noted, however, that an additional router, such as a 
border router, is not necessary in providing communication between the first SIP phone 112 
and the second SIP phone 114. 

Multimedia packets received by the media router 106 comprise, among other portions, 
a header and an IP packet data portion. FIG. 3 is a simplified diagram illustrating the above 
mentioned parts of a multimedia packet 164. The header 162 of a multimedia packet 164, at 
a minimum, comprises, among other portions, at least a source portion 166 that identifies a 
source address from which the multimedia packet arrived, and a destination portion 168, that 
identifies a destination address to which the packet is addressed. As described above, an IP 
header may comprise many other portions, such as, but not limited to, an RTP header or an 
RTCP header. 

While FIG. 1 provides a communication system 102 wherein the destination device is 
the second SIP phone 1 14, multiple destination devices may be connected to the first SIP 
phone 1 12 via the media router 106. The IP packet data portion 172 of the multimedia packet 
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comprises the remaining portion of the multimedia packet 164, which comprises data that is 
being transmitted to the destination device located at the destination address. 

When a multimedia packet is transmitted from the first SIP phone 112 (FIG. 1) to the 
media router 106, the source portion 166 of the header 162 comprises the IP address and port 
of the first SIP phone 112, and the destination portion 168 of the header 162 comprises the IP 
address and port of the media router 106. Once again, it should be noted that the header 162 
may comprise numerous other portions, or headers, therein. If an intervening device 1 1 6 is 
located between the first SIP phone 112 and the media router 106, the intervening device 116 
receives the transmitted multimedia packet prior to the media router 106. Before transmitting 
the received multimedia packet to the media router 1 06, the intervening device 116 may 
change the properties of the header 162 of the received multimedia packet 164, so that the 
source portion 166 of the header 162 reflects that the multimedia packet has been transmitted 
from the intervening device 116. Therefore, when the multimedia packet is received by the 
media router 106, the media router 106 is not capable of determining the original source of 
the multimedia packet since the source portion 166 of the multimedia packet reflects that the 
source of the multimedia packet is the device from which the multimedia packet was last 
transmitted. 

The ability to determine the original source of a multimedia packet is important to 
devices such as, but not limited to, firewalls, where multimedia packet entry into a device 
associated with the firewall is dependent upon the source of the received multimedia packet. 
Therefore, determination of an original source of a received multimedia packet is desirable, 
and within certain devices, such as a firewall, necessary. 

To enable determination of the original source of a multimedia packet the CAM 148 
(FIG. 2) and the network processor 142 are utilized. The network processor 142 performs a 
series of actions on a received multimedia packet after receipt by the media router 106. 
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Generally, the network processor 142 removes a level two header, such as, but not limited to, 
a link protocol header, or layer two header, from the received multimedia packet. An 
example of a link protocol header may include, but is not limited to, an Ethernet header or 
high-level data link control (HDLC) header. The layer two header is removed so that a layer 
three header located within the data packet, and a layer four header located within the data 
packet, may be examined by the media router 106. The layer three header comprises source 
IP and destination IP addresses, and the layer four header comprises source and destination 
ports, as assigned by the session router 104 or directly assigned to the media router 106. The 
layer three and four headers may be validated and changed by the network processor 142 via 
use of the CAM 148, as is described below. 

FIG. 4 is a multimedia packet flow table 202 located within the CAM 148 that is 
utilized by the network processor 142 to enable determination of an original source of a 
received multimedia packet. As is shown by FIG. 4, the multimedia packet flow table 202 
comprises a source IP address column 212, a destination IP address column 214, a source 
port column 216, a destination port column 218, a weight column 222, a flag column 224, 
and a translation addresses column 226, each of which is described below. 

Each column 212, 214, 216, 218, 222, 224, 226 within the multimedia packet flow 
table 202 comprises a series of cells, which are utilized to store information associated with 
their corresponding column name. Therefore, each source IP address cell comprises a source 
IP address; each destination IP address cell comprises a destination IP address; each source 
port cell comprises a source port; each destination port cell comprises a destination port; and 
each translation address cell comprises replacement layer three addresses including a 
replacement source address and a replacement destination address. It should be noted that the 
translation address cell may also comprise a replacement source port and a replacement 
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destination port, although, for simplification purposes, use of a replacement source port and a 
replacement destination port are not described herein. 

The weight column 222 is utilized to associate a weight value with each grouping of a 
source IP address, destination IP address, source port, and destination port (i.e., a first source 
5 IP address, a first destination IP address, a first source port, a first destination port). 

Therefore, a group comprising the first source IP address, first destination IP address, first 
source port and first destination port is assigned a single weight value. Hereinafter, a group 
of cells comprising a first source IP address, a first destination IP address, a first source port 

2J and a first destination port is referred to as a first table group; a group comprising a second 

1 

HI 10 source IP address, a second destination IP address, a second source port and a second 

ft! destination port is referred to as a second table group, etc. The weight value is utilized to 

* assign priority to one table group over another table group. A detailed explanation of the 

fH 

Jj! weight value and a demonstration of its use are provided below. 

iu 

j*3 A universal bit, represented by the variable X, may be utilized by a cell within the 

III 

15 multimedia packet flow table 202 to represent that any value is acceptable for that particular 
cell. Specific to the present source determination system, the universal bit is utilized within 
the source IP address column 212 and the source port column 216 to allow acceptance of a 
multimedia packet from any source, wherein the destination IP address and destination port 
of the received multimedia packet are similar to a destination IP address and destination port. 

20 Universal bit acceptance is described below with reference to FIGS. 5A, 5B and SC. 

The flag column 224 may provide a latch bit, designated as L, for an associated table 
group to indicate that multimedia packets may be received by a new source that is not yet 
represented by the CAM 148. In fact, the number of latch bits provided within the 
multimedia packet flow table 202 indicates the number of multimedia packet sources, not yet 

25 provided for by the CAM 148, that will be allowed to communicate with the media router 
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106. The latch bit is utilized in combination with universal bits during inspection of a 
received multimedia packet. The latch bit is utilized to specify if a new table group should be 
created within the CAM 148 for the received multimedia packet that comprises an acceptable 
destination IP address, an acceptable destination port, a newly received source IP address, 
and a newly received source port. 

If a latch bit is associated with a table group, and a universal bit is located within both 
the source IP address cell of the table group and the source port cell of the table group, then 
the following steps are performed. First, a new table group is created wherein the value 
stored within the destination IP address cell of the new table group, and the value stored 
within the destination port cell of the new table group, is copied from the prior table group 
comprising the latch bit and universal bits. In addition, the source IP address cell of the new 
table group stores therein the IP address of the source of the received multimedia packet, and 
the source port cell of the new table group stores therein the port address of the source of the 
received multimedia packet. 

It is preferred that the weight of a table group comprising universal bits be lower than 
the weight of a table group not comprising universal bits. As a result, the table group not 
having universal bits will be selected by the network processor 142 prior to selection of the 
table group comprising universal bits. 

A second step performed if a latch bit is associated with a table group, and a universal 
bit is located within both the source IP address cell of the table group and the source port cell 
of the table group, is to add a high weight factor value to the new table group that is 
comparable to a weight factor value utilized for a table group not having universal bits. It 
should be noted that a latch flag is not set for the new table group. A third step performed is 
to delete the original table group, comprising the latch bit and universal bits, from the 
multimedia packet flow table 202. The order of the prior mentioned steps ensures that after a 
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first multimedia packet is received, which is defined by the original table group, the original 
table group is no longer utilized for allowing receipt of multimedia packets. The layer three 
header of multimedia packets received by the media router 106 that comprise characteristics 
designated by a table group is then replaced with the translation addresses associated with the 
table group. 

An example of a multimedia packet flow table 252 is provided by FIGS. 5 A, 5B, and 
5C for purposes of demonstrating the above mentioned steps. FIG. 5 A provides a multimedia 
packet flow table 252 comprising a source IP address column 262, a destination IP address 
column 272, a source port column 282, a destination port column 292, a weight column 302, 
a flag column 312, and a translation addresses column 322. Each of the above mentioned 
columns comprises a number of cells, four of which are provided in the present example. 
Four rows of cells, or table groups, are provided by the multimedia packet flow table 252, 
namely, a first table group 332, a second table group 334, a third table group 336, and a 
fourth table group 338. 

If the header portion 162 of a received multimedia packet comprises a source IP 
address of 1.1.1.1, a destination IP address of 2.2.2.2, a source port of 1001 and a destination 
port of 2001, the CAM 148 returns associated translation addresses, comprising a 
replacement source address and a replacement destination address, to the network processor 
142. As shown by FIG. 5A, the translation addresses associated with the first table group 332 
are 10.1.1.1/20.2.2.2. The translated addresses are incorporated into the header 162 of the 
received multimedia packet by the network processor 142, thereby designating a new source 
address of 10.1.1.1 and a new destination address of 20.2.2.2 for the multimedia packet. 

If the header portion 162 of a received multimedia packet comprises a source IP 
address of 2.2.2.1, a destination IP address of 2.2.2.2, a source port of 3000 and a destination 
port of 2001, the CAM 148 returns associated translation addresses, comprising a 



19 



TKHR Docket No.: 50115-1110 

replacement source address and a replacement destination address, to the network processor 
142. As shown by FIG. 5 A, the translated addresses associated with the third table group 336 
are 20.2.2. 1/20.2.2.2. The translated addresses are incorporated into the header 162 of the 
received multimedia packet by the network processor 142, thereby designating a new source 
address of 20.2.2.1 and a new destination address of 20.2.2.2 for the multimedia packet. 

Instead, if the header portion 162 of a received multimedia packet comprises a source 
IP address of 3.3.3.3, a destination IP address of 2.2.2.2, a source port of 5000 and a 
destination port of 2001, the CAM 148 returns associated translation addresses, comprising a 
replacement source address and a replacement destination address, to the network processor 
142. As shown by FIG. 5 A, the translation addresses associated with the fourth table group 
338 are 30.3.3.3/20.2.2.2. The translated addresses are incorporated into the header 162 of 
the received multimedia packet by the network processor 142, thereby designating a new 
source address of 30.3.3.3 and a new destination address of 20.2.2.2 for the multimedia 
packet. 

Alternatively, if the header portion 162 of a received multimedia packet comprises a 
source IP address designated by a universal bit, a destination BP address of 2.2.2.2, a source 
port designated by a universal bit, a destination port of 2001, and a set latch bit, the following 
occurs. As is shown by FIG. 5B, a fifth table group 342 is created having similar 
characteristics to the second table group 334. Specifically, the destination IP address 
(2.2.2.2), destination port (2001), and translation addresses (X/20.2.2.2) are copied from the 
second table group 334 to the fifth table group 342. It should be noted that the translation 
address, X/20.2.2.2, establish that the replacement source address is the address of the latest 
source of the multimedia packet and the replacement destination address is 20.2.2.2. The 
latch bit is not set in the fifth table group 342 and the weight for the fifth table group 342 is 
set to be equivalent or similar to other table groups 332, 336, 338. 
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The IP address and port of the device that last transmitted the received multimedia 
packet to the media router 164, is stored in the source IP address column 262 and the source 
port column 282, respectively, within the fifth table group 342. As is shown by FIG. 5C, 
information within the second table group 334 is then deleted from the multimedia packet 
flow table 252. Since the fifth table group 342 comprises a source IP address, destination IP 
address, source port, destination port, weight, and translation addresses, the fifth table group 
342 is capable of being used to direct a received multimedia packet to a destination. In 
addition, since the latch bit is no longer set within the multimedia packet flow table 252 and 
the universal bits within the source IP address column 262 and the source port column 282 
have been deleted, the media router 164 will no longer accept multimedia packets from a 
device that does not comprise a source IP address, destination IP address, source port and 
destination port combination, defined by a single table group. 

After the new source IP address and source port have been determined, the media 
router 164 may transmit the source IP address and source port to the session router 104. The 
session router 104 may then be utilized to determine additional information about the source 
of the received multimedia packet such as, whether the latched source address is valid. The 
media router 164 will inform the session router 104 of the latched source address using the 
protocol used for flow setup and tear-down. In addition, it should be noted that more than 
one combination of universal bits and latch flags may be utilized within the multimedia 
packet flow table 252 to allow the introduction of more than one new source device for 
communication with the media router 164. 

It should be emphasized that the above-described embodiments of the present 
invention, particularly, any "preferred" embodiments, are merely possible examples of 
implementations, merely set forth for a clear understanding of the principles of the invention. 
Many variations and modifications may be made to the above-described embodiment(s) of 
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the invention without departing substantially from the spirit and principles of the invention. 
All such modifications and variations are intended to be included herein within the scope of 
this disclosure and the present invention and protected by the following claims. 
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